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ABSTRACT 

This thesis focuses upon a new method for verifying the correct operation of a complex, 
high speed fiber optic communication network. These networks are of growing importance 
to the military because of their increased connectivity, survivability, and reconfigurability. 
With the introduction and increased dependence on sophisticated software and protocols, 
it is esscrtial that their operation be correct. Because of the speed and complexity of fiber 
optic communication networks being designed today, they are becoming increasingly 
difficult to test. Previously, testing was accomplished by application of conformance test 
methods which had little connection with an implementation’s specification. The major 
goal of conformance testing is to ensure that the implementation of a profile is consistent 
with its specification. Formal specification is needed to ensure that the implementation 
performs its intended operations while exhibiting desirable behaviors. The new 
conformance test method presented is based upon the System of Communicating Machirie 
model which uses a formal protocol specification of the implementation to generate a test 
sequence. 
The major contribution of this thesis is the application of the System of Communicating 
Machine model to formal profile specifications of the Survivable Adaptable Fiber Optic 
Embedded Network (SAFENET) standard which results in the derivation of test sequences 


for a SAFENET profile. The results of applying this new method to SAFENET’s OSI and 












Lightweight profiles are presented. 
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I. INTRODUCTION 


A. PURPOSE 
The Survivable Adaptable Fiber Optic Embedded Network (SAFENET) is part of the 


United States Navy’s Next Generation Computer Resources (NGCR) program and 
represents an effort to meet the data transfer demands of current and future naval shipboard 
mission critical computer systems through development of standard computer network 
profiles. SAFENET represents a Local Area Network (LAN) grouping of standards, 
encompassing the seven ISO/OSI model layers. SAFENET is a program being researched 
and developed by a joint Navy-Industry working group to formulate standard commercial 
network methods to fit the requirements of the Navy’s various combat platforms. Whenever 
possible, the joint working group intends to select well developed industry standards. The 
Navy’s NGCR team is chartered to investigate methods for future shipboard hardware and 
software development to meet the Navy’s requirements of survivability, increased 
connectivity, performance and future system growth capabilities (GREE89] [HDBK92]. 
SAFENET is an effort to meet the needs of current and future systems used aboard the 
Navy’s combat ships, submarines, and aircraft. 

Over the course of time, network designers learned that ambiguous rules can trigger 
undesirable sequences of events which can have adverse effects on the best design; 
therefore, it is essential that communication networks and their protocols be adequately 
tested. Entire networks, with possibly hundreds or even thousands of attached computers 
can be rendered essentially useless by a faulty protocol or profile. With every passing day 
our society is becoming more dependent on communication networks and their protocols. 
Consequently, with so many lives and costly equipment at stake it is imperative to test these 
profiles and protocols to ensure that they perform as intended. This thesis presents a 


conformance test method that is based upon earlier work [MILL90]. In this thesis, the 


conformance test method utilized is based upon a formal specification. In addition, 





ee a 


applications of the test method using real world SAFENET profiles as examples will be 


demonstrated. 


B. BACKGROUND 


Currently, in the Navy, computers are usually found configured in point-to-point 
interfaces. However, the growing trend of distributed architectures in modern naval 
combat systems requires a greater degree of system integration than present point-to-point 
interfaces can support. As a result, the SAFENET standards are being developed to solve 
communications connectivity and system integration problems by providing the shipboard 
computers with the capability to communicate with multiple devices and application 
programs over a single Input/Output port through the use of a computer network and to 
provide future system growth capacity. 

To ensure that the elements of a complex communications network such as SAFENET 
communicate reliably once the system has been implemented, the protocols of the system 
should be verified against all system design requirements. In this manner, instances of 
incompleteness in a protocol specification can be located using protocol verification 
techniques. Provided formal specifications have been done, conformance testing is an 
essential step to ensuring accomplishment of intended functions without error. Effectively 
testing protocols with other software and hardware systems presents a difficult problem. 
Conformance testing’s major goal is to ensure that the implementation of the protocol is 
consistent with its specification. Therefore, it is highly advantageous that the specification 
be expressed in a formal model that has been formally verified. A recent paper by Miller 
(MILL90], pointed out the developing rift between specification and verification, and 
between these two and conformance testing. Protocol models, designed for specification 
purposes, tend to have powerful program language constructs, which simplify specification 


but leads to a higher degree of verification and analysis difficulty. The Communicating 


Finite State Machine (CFSM) model is too simple for the specification of modern, complex 





protocols because this protocol model is designed primanly with analysis in mind 


[LUND91]. 


C. CONTENTS 


This thesis attempts to bridge the gap between SAFENET specification and testing. 
Assuming that all SAFENET protocols are not available in a form convenient for testing, 
simplifying the difficulty associated with verification, analysis and testing, we start from a 
protocol model called Systems of Communicating Machines (SCM). A procedure is 
presented for the generation of a test sequence for a protocol specified in terms of the 
SAFENET model. Then, the SAFENET procedure is used to generate a test sequence for a 
SAFENET protocol implementation. 

The testing of any complex software is known to be a difficult problem, and this 
certainly applies to the testing of SAFENET protocols. Because SAFENET protocols are 
critical to so many systems, it is a problem which cannot be avoided or ignored. The 
procedure presented in this thesis does not detect all errors or combinations of errors. Only 
exhaustive testing can accomplish this, but substantial resources are required. The approach 
does, however represent an attempt to exercise a portion of a SAFENET protocol machine. 
thereby providing some assurance that the implementation fulfills its purpose. 

Presently, there are two standards under development SAFENET I and SAFENET II. 
This thesis focuses on SAFENET I which uses the American National Standards Institute 
(ANSD Fiber Distributed Data Interface (FDDI) LAN that operates at 100 Mbps. In the 
following chapter the FDDI standard is discussed. In Chapter II], the SAFENET Draft 
Standard is discussed followed by Chapter iv, which discusses problems found in the 
SAFENET Draft Standard. In Chapter V, the testing of fiber optic links is discussed. In 
Chapter VI, the test procedure is applied to the SAFENET protocol. The final chapter 


surmmarizes the thesis. 


ll. FDDI BACKGROUND 


The FDDI standard is focused on the comprehensive implementation of 
communications through fiber optics; with fiber optics, information is passed through 
moduiated beams of light on glass fiber rather than the more antiquated electronic pulses 
on copper wire. In large backbone Local Area Networks (LANs), FDDI has several 
advantages over copper wire. Fiber is oblivious to lightening strikes, to the Electro- 
Magnetic Pulse (EMP) phenomenon associated with nuclear detonations and to their 
resultant current surges that can damage connected equipment and cause safety hazards. 
Furthermore, fiber is not subject to radio or Electro-Magnetic Interference (EMI) and is 
generally less restrictive in its environment, requiring far less space in existing cable runs. 

FDDI utilizes two counter-rotating token rings. The typical FDDI configuration has 
the primary ring carrying data and the secondary ring being used for automatic bypass and 
recovery (Figure 1). Current networks in service are generally comprised of CSMA/CD 
protocols, which limit transmission rates to 10 Mbps, shorter cable runs, and rapidly 
decreasing efficiency as the network load increases because of data collision resolution. 
The use of a ring topology offers the advantage of data collision elimination, which 
provides for very high effective data rates. Unlike CSMA/CD topologies (such as 
Ethermet), FDDI’s performance does not degrade significantly with increased levels of 
traffic, up to 95% of its rated capacity. FDDI networks can bypass hardware failures. When 
a node or link fails, the two counter rotating paths wrap together around the fault thus 
allowing continued communications. Any fault on FDDI dual rings can be isolated, 
keeping the remainder of the rings completely active. When the fault is corrected the fiber 
optic ring reconfigures automatically. This ability to adapt to breaks or node failures helps 


ensure reliability of the system and data availability in transfer. 
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Figure 1 Typical FDDI configuration 

A special bit pattern, called a token, is continuously circulated by the FDDI ring. 
Stations transmit data by capturing the token, transmitting their traffic, and sending the 
token to the next station on the network until a complete circuit is made. FDDI supports 
two types of traffic transmissions: synchronous and asynchronous. Synchronous service is 
designed for applications with predictable bandwidths and critical response times. 
Asynchronous services are designed for applications with bursty, widely varying 
bandwidth requirements. To accommodate asynchronous, “non-deterministic” traffic a 
Target Token Rotation Time (TTRT) is defined and negotiated during ring initialization. 
Each station maintains the same value for TTRT. Each station’s Token Rotation Timer 
(TRT) is initialized to TTRT when enabled. The TRT counts down until TRT =0 and is then 
reset to TTRT. The variable Late Count (LC) is initialized to zero (LC = 0) and is 


incremented each time TRT reaches zero. In this manner, the Late Count counter records 
the number of times TRT has expired since the token was last received by a designated 
station. If TRT does not reach zero and LC is zero, the token is considered to have arrived 
early. When a station receives the token early, after transmitting any synchronous frames, 
it may transmit asynchronous frames for a period not to exceed the remaining TRT. Once 
the allotment of asynchronous frames are transmitted, the token is passed to the next station 
and both TRT and LC are reinitialized [STAL88]. Synchronous traffic is “deterministic” 
because each station is guaranteed token service within a specified time limit and for a 
specified allocation. In the event that a station has asynchronous, ‘“‘non-deterministic” 
traffic to transmit, upon receipt of the token the station, first, tansmits any synchronous 
traffic up to its allocation; then, if there is time remaining as the result of an early token 
arrival due to decreased synchronous allocation usage or if excess bandwidth is present, the 
asynchronous traffic will be transmitted. 

Utilizing FDDI as the backbone LAN offers other advantages. In addition to satisfying 
the need of connecting LANS together without compromising inter-LAN speed, FDDI 
offers capability that will enable future technologies, including circuit switching. Like most 
networks, FDDI is a packet switched network, utilizing FDDI packets to facilitate the 
efficient transmission of data in various sizes. FDDI frames vary in length, have their own 
delimiting start and end markers, and contain their own destination addresses (Figure 2). 
By using an upward compatible extension of FDDI known as FDDI-II, FDDI gains the 
capability to perform circuit-switched service in addition to normal packet switching 
[ROSS89]}. This permits future special applications which require real-time response from 
the network, including digital voice; rapid updating of tactical displays in battle may be 


another application. Ross describes the circuit switched connection as a “data stream,” 


which provides for the transmission of continuous (analog) data. 











< 4500octets J 32bits 





Figure 2 FDDI Frame Format 


FDDI rings support two types of stations: dual attach stations (DAS), which attach 
directly to the ring, and single attach stations (SAS), such as PC’s and work stations. Each 
DAS has four fiber connections, two to receive and transmit on the primary ring, and two 
to receive and transmit on the secondary ring. A typical DAS can be a concentrator, bridge, 
router, server, minicomputer or mainframe. Multiple DASs are linked together to form the 
network backbone. A SAS can be immediately isolated in case of fault detection without 
disrupting traffic on the ring. 

In a distributed network environment, all the DASs in a FDDI ring participate in 
network capability, fault recovery, management, and network initialization. Internal DAS 
timers and logic control resolution of all ring failures provide bypass handling. Therefore. 
the counter-rotating ring topology allows the network to continue functioning in the event 
that either a node or link is lost. It is this survivability, in addition to its very high 
bandwidth, that makes FDDI most suitable to a battle environment. Optical fiber minimizes 
interference and signal degradation, and minimizes signal loss over long cable runs. Due to 
the extremely large bandwidth of fiber, bit-serial transmission may be used, offering the 
advantage of hardware simplicity, decreased complexity, and increased reliability 
[ROSS89]. Reliability is a key factor for the Navy in both normal peacetime operations and 
while at battle. This interest in reliability and communications connectivity led to the 


development effort of Survivable Adaptable Fiber Optic Embedded Network (SAFENET). 
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Figure 3 SAFENET Protocol Profile 


I. SAFENET BACKGROUND 


SAFENET is based on the FDDI token-ring standard and incorporates profiles for both 
ISO compatibility and real time performance. By employing the seven layer ISO reference 
model for Open Systems Interconnection (OSD, SAFENET specifies protocols at each 
layer of this model, defining the complete SAFENET profile. In SAFENET, this protocol 


profile is organized in two ways: by service partitions and by defined profiles. 


A. SERVICE PARTITIONS 

The first method of SAFENET’s communicating architecture divides the protocol 
profile into three service partitions: user services, transfer services, and LAN services. Each 
of these partitions encompasses a portion of the seven layers of the ISO reference model. 
Figure 3 delineates the seven layers of the ISO reference model on the left, the major 
elements of the SAFENET profile in the center, and the service partitions on the right. The 
user services partition corresponds to the session, presentation, and application layers of the 
ISO reference model (layers 5-7) and is that portion of the SAFENET profile in which users 
interact with the network. The user services partition afford SAFENET users with the 
capability to interact with, manage, and respond to the underlying transfer services. In the 
center of the SAFENET profile lies the transfer services partition. It corresponds to the 
network, transport and Logical Link Control (LLC) sublayer of the Data Link Layer, (layers 
2-4) of the ISO reference model. Through these services reliable communication 
mechanisms are provided to SAFENET users. The LAN services partition is that part of the 
SAFENET profile which performs the actual data transfer and corresponds to the physical 
layer of the [SO reference model as well as the media access control sublayer of the data 
link layer (layers 1-2). The LAN services consist of the upload and download ability to get 


data on and off the physical medium in a controlled manner. 


B. PROTOCOL SUITES 


The second descriptive method of SAFENET communications architecture separates 
the protocols into defined profiles: the OSI protocol profile, lightweight protocol profile, 
and the combined protocol profile. As depicted in figures 4, 5, and 6, these profiles define 
the three distinct implementation classes permitted in SAFENET. It is not required that all 
stations on a given SAFENET network implement the same profiles. Each respective 
profile describes a specific combination of network protocols defined within SAFENET. 
When designing a SAFENET station, at least one of the profiles (OSI, Lightweight, and 
Combined profiles) must be implemented. However, network designers must ensure the 
presence of sufficient profiles at each station to ensure that the system meets its designed 
communications connectivity. Some of the services and protocols are common to all 
implementation classes and others are used only in the OSI or lightweight profiles.The 
SAFENET Time Service (STS) is required for all protocol suite implementations. 

The OSI protocol suite, possessing protocols and services based upon ISO standards, 
provides complete OSI compliant networking services to systems which require it. The OSI 
protocol suite consists of Manufacturing Automation Protocol (MAP) private 
communications, ISO File Transfer, Access and Management (FTAM), Directory Services, 
Association Control Service Element (ACSE), Remote Operations Service Element 
(ROSE), System Management Application Service Element (SMASE), Common 
Management Information Service Element (CMISE), presentation and session layers, 
Connection-Oriented Transport Protocol (COTP), ISO Connectionless Transport Protocol 
(CLTP) which allows the user to transmit a single unit of data, datagram, without 
establishing a connection, ISO Connectionless Network Protocol (CLNP) which provides 
services for network routing and for the segmentation and reassembly of transport layer 
messages that are too large for the underlying communications service, ES/IS routing 
exchange protocol which provides stations with the ability to associate a data link layer 
address with a given network layer address, IS/IS intra-domain routing protocol which 


dynamically determines routes to pass data between intermediate systems, LLC type | 


10 


(connectionless) protocol and the FDDI protocols. The ISO connection oriented Transport 


protocol class 4 (TP4) is required within the transfer services partition [ISO870]. This is 


done to ensure interoperability in an open systems environment. The OSI protocol suite is 
basically required when either the interoperability of independently developed nodes is a 
driving consideration, or the file handling capabilities of FTAM are required, or increased 
complexity requires network management; however, it adds this capability at the expense 
of delayed data flow and inability to supply multiple users simultaneously [(KOCH91] 


{PAIG90}. Figure 4 shows an overview of the OSI protocol suite. 
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Figure 4 Overview of the OSI Profile 
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In circumstances where control of timing is critical from a resource point of view, the 
lightweight protocol suite provides process to process message passing services. The 
message passing services support point to point, multicast, and remote procedure call 
(transaction) styles of service; however, multicast capability is limited to a single logical 


LAN segment (HDBK92]. The lightweight profile provides real time data transfer 





capability to various systems, as well as providing added options. The lightweight protocol 
suite Consists of lightweight application services, the Xpress Transfer Protocol (XTP), ISO 
CLTP, ISO CLNP, ES/IS routing exchange protocol, IS/IS intra- domain routing protocol, 
LLC protocol and the FDDI protocols. This profile permits implementors to develop a set 
of communication services which support the performance and architecture requirements 
of a specific system. The lightweight profile provides a limited set of network management 
capabilities. If this service is required then the combined protocol suite must be utilized. 
Finally, while this lightweight protocol suite provides fast data transfer, it does not adhere 
to the ISO standard protocol and therefore is very system specific [KOCH91}. Figure 5 


shows an overview of the lightweight profile. 
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Figure 6 Overview of the Combined Profile 


The combined profile is essentially the union of the OSI and lightweight protocol 
profiles. The combined protocol suite is intended for situations that require the capabilities 
of both the OSI and lightweight protocols. Therefore, all the protocols, services and 
capabilities of OSI and lightweight profiles are included. Additionally, network 
management protocols and services are provided for those protocol enrities contained 


within the lightweight profile. However, because of the combined capability of this suite, it 
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requires much more complex development energy and cost [KOCH91]. Figure 6 shows an 


overview of the combined profile. 


C. SAFENET TOPOLOGY 

The basic topology design for SAFENET utilizes a redundant ring structure as shown 
in figure 1. The critical element of SAFENET’s topology is the trunk Coupling Unit (TCU). 
The TCU device enables a station to insert or remove itself from a network ring. The TCU 
is a 2x2 optical bypass switch, which is controlled by an electrical signal from the attached 
station. The TCU has the capability to readily isolate a failed station from the network, 
thereby contributing to system reliability [PAIG90]. Optical signals are transmitted in 
opposite directions on each of the two rings. It is clear from this redundant ring topology 
that accurate and timely data flow is essential to the performance of SAFENET. 
Accordingly, as its name implies, SAFENET uses fiber optic technology as the physical 
medium in which data is exchanged. Consequently, this fiber optic technology forms the 
backbone of SAFENET’s development. 


D. SAFENET FIBER OPTIC DEVELOPMENT 
The developers of SAFENET chose to employ a newer fiber optic technology over the 


older copper cables. For optical cables incorporate a number of excellent properties which 
provide data exchange for high-capacity transmission systems [JOHN87]. A major 
advantage of fiber optics is the large bandwidth times distance products obtained which 
allow data transmission rates of up to several Gbps [LI1983]. Furthermore, today’s fibers 
typically offer bit rates of several hundred Mbps {IFOC84) and [LUND91). Additionally, 
since glass is a dielectric medium, immune to electromagnetic interference and free from 
sparking, these optical fibers are useful in EMI-rich and other hostile environments. Low 
attenuation combined with its extremely small physical dimensions make optical fibers the 
physical medium of choice [FINL84}. 
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As shown in Figure 1, each network ring is composed of TCUs and connecting trunk 
cables. The primary and secondary ring trunk cables are intended to be physically separated 
to enhance survivability in the event of battle damage. This placement strategy of allowing 
key network components (e.g., TCU and DAS) to be separated will allow the network to 
absorb some damage without the entire system losing its ability to operate. 

It is understood that for an active ring either a node failure or a fiber break will cause 
a fatal crash. To correct this deficiency, SAFENET has added a second ring in the opposite 
direction as discussed earlier. This configuration allows for two types of network 
reconfiguration in the presence of a fault in the cable: ring hop/hold and ring wrap. Ring 
wrap is caused by a fault in the primary and secondary rings, the faulty sections of both 
rings are isolated by forming one or more rings out of the remaining portions of the primary 


and secondary rings [HDBK92}. 
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Figure 7 An overview of component systems comprising SAFENET 





Figure 7 depicts the manner in which each component or warfare speciality area is 
unified into a whole. Each component, alone, is a system; yet, the synergism inherent in 


SAFENET's configuration and survivability features make it everi more formidable. 


Iv. THE SAFENET STANDARD 


A. THE SAFENET STANDARD AND ITS TESTABILITY 


The SAFENET manual provides requirements for the implementation of fiber optic 
local area networks which are intended for use in support of mission critical computer 
resources. The SAFENET standard is organizationally well written, but it is large, and 
complex in its potential interprofile relationships. Each protocol within a SAFENET profile 
can be viewed as a finite state machine. The task of figuring out which protocol machines 
are expected to communicate within each profile can be awesome and daunting to some. 
While concrete design specifications are not expected to be contained in the manual. 
abstract design specifications should have and would have proven very useful to designers. 
As a result of neither abstract nor concrete design specifications, the SAFENET manual 
must be closely scrutinized and intra-profile relationships gleaned to garner all implicit 
relationships bit by bit in order to attain a formal specification. 

The standards manual references in several cases existing standards; however, there 
are requirements which SAFENET references that are not yet completely formulated and 
are currently in draft status. SAFENET’s Network Development Guidance and 
Conformance Test Guidance are two such requirements whose standards are listed as 
drafts. The Development Guidance and the Conformance Test Guidance are very crucial 
for SAFENET development. Systems Analvst and Designers will use these two manuals 
extensively to develop their implementation, in conjunction with the SAFENET standards 
manual. In addition, the Quality Assurance and Testing team will use these two manuals 
extensively to develop a test package. As a result of these two important publications being 
in their draft stages of development, the difficulty of testing a SAFENET implementation 
greatly increases. Consequently, the issue of whether we can implement SAFENET and 
perform the conformance testing without these two publications, begins to favor having ihe 


availability of both publications. Development and testability are greatly enhanced with the 
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availability of both the SAFENET Network Development Guidance and the SAFENET 


Conformance Test Guidance. 


B. PROBLEMS WITH THE CURRENT SAFENET STANDARD 


While SAFENET represents a major step forward in communications connectivity, 
this breakthrough is not without its share of problems and potential pitfalls. Typically, 
problems are associated with or attributed to any new introductory system. The current 
manual of SAFENET’s standard is neither a users manual nor a technical manual. It is 
essentially a SAFENET standard document of specification that Development teams can 
use as guidelines for creating, implementing and testing a SAFENET network. 
Consequently, the current standard does not contain tutorials or a listing of descriptive 
features from a users’ point of view. The standards manual is inadequate for describing 
specific features, user protocol interfaces, and for navigating between and within protocols. 
These features are expected to be contained in an implementor’s users manual. 
Additionally, the current standard while containing much technical information is 
insufficient in that context, and the manual alone lacks the technical data necessary to 
facilitate a SAFENET installation in accordance with Military Specifications (MIL- 
SPECS). 

Most of the fiber optic components used commercially meet MIL-SPECS, that is they 
conform to the quality control standard demanded by MIL-SPECS; however, the fiber optic 
bypass switch, contained within the TCU, did not perform in accordance with MIL-SPECS 
[GREE89}. As mentioned earlier, the fiber optic bypass switch bypasses a station which 
does not energize an electrical signal to this switch Consequently, the SAFENET 
committee will have to expend research and developm~ + resources in this area to comply 
with MIL-SPECS. The specification of militarized components makes SAFENET lose the 


modular “plug” compatibility desired with standard off-the-shelf commerically available 


components, but this is seen as a necessary trade-off to enhance reliability and survivability. 





In theory, ANSI FDDI can support the reliability and survivability features that are 
proposed for SAFENET, called dual path reconfiguration. SAFENET’s approach to 
enhanced survivability was to initially specify the wrap method and after that specification 
is completed to actively work on development of a specification which uses both ring hop 
and wrap methods [GREE89]. The ANSI FDDI standard provides for the dual ring wrap 
reconfiguration technique; however, the ring hop reconfiguration technique is not 
supported in ANSI FDDI. The Navy’s interest is expected to have a positive impact on 
development of the ring hop feature. But, whether this hop capability does become in 
reality a viable reconfiguration technique will depend on whether FDDI chip set 
manufacturers find the hop method cost effective to implement. 

Another major area of concern is the support for time synchronization. The 
distribution of high precision, synchronized, digital time value among the components of a 
distributed real time system on a platform wide scale is one of the requirements that exist 
in all Navy SAFENET tactical systems. During the operational employment of a tactical 
system or platform, time synchronization is needed continually. The SAFENET Time 
Service (STS) provides for the distribution of time information and the synchronization of 
distributed clocks within a system. This capability is necessary for activities such as 
correlating information provided by various sensors to control weapons, to conduct post 
event reconstruction of critical events and to accomplish time critical diagnostic tests. 

In searching for a candidate protocol for time synchronization, the SAFENET 
committee found that no true industry-wide standard existed [GREE89]. The Network 
Time Protocol (NTP), which utilizes a hardware clock of identifiable accuracy bound at 
each computing element employs a logical synchronized clock as its base. To support the 
STS each station or node is required to have a local time source, called a Network Clock. 
The Network Clock includes both the software and hardware components necessary to 
implement a time source. The STS is partitioned into three functional areas: the clock 
synchronization service, the user time service, and the time management service. Thus, the 


STS resident in each node uses the Network Clock to provide the current value of time, 
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clock quality and accuracy of time value to users in the local SAFENET node and to 
synchronize with other Network Clocks in the network. It is anticipated that major 
platforms will have clocks utilizing satellite synchronization; this concept appears to 
facilitate the Navy’s application. 

The prototyping activity in progress within the NGCR community is looked upon to 
supply the critical answer as to whether distributed Network Clocks will satisfy naval 
requirements. Surprisingly, SAFENET has established no error bounds or performance 
requirements for the individual Network Clocks in a network. It is assumed that the system 
implementors will use components of sufficient quality to meet the system specific 
requirements. The quality of the components used will have a direct impact on the level of 
synchronization achieved. In all aspects, this represents a potential pitfall; clock 
synchronization performance is a critical area that will require close attention during 
system design. The performance requirements of the system will need to be specified and 
the appropriate configuration parameters determined. 

One primary necessity for naval tactical systems is the need to support real time 
communications, be it, periodic and aperiodic, multicast and point to point, or low latency 
communications. The ability to delay or even abort low value communications in favor of 
more urgent communications is a problem for both present and future applications, 
particularly in the event of momentary insufficient data communication resources 
[GREE89]. Because of the nature of timed token behavior, ANSI FDDI provides only two 
levels for data frames, synchronous and asynchronous traffic. This methodology has no 
effect on which station obtains the right to transmit data next. The basis for SAFENET I, 
the IEEE 802.5 standard provides a three bit priority field which supports eight levels of 
priority and is used for selecting the token holder, the next station allowed to transmit 
frames. The viewpoint of the SAFENET committee is that eight levels of priority is 
inadequate for meeting system requirements. SAFENET did not provide any real time 
specification for this area and thus this led to the SAFENET Lightweight Protocol profile. 
The Lightweight Protocol candidate selected was the XTP protocol which is non- 
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proprietary, has the potential for industry standardization and provides the needed support 
for real time communications. The development of SAFENET requirements used the XTP 
protocol as a reference for what is possible and practical and also as a means of feedback 
to the XTP developers the requirements which were not met by the current version of the 
XTP protocol. Thus, the key and potential problem for the Lightweight Protocol profile is 
how well it supports real time, prioritized traffic in present and future applications. 

Presently, in the Lightweight profile only the XTP SAFENET hex address format can 
be used [HDBK92]. Particularly in stressful moments, hex addressing does not lend itself 
very well to human recall as the primary means of station addressing. Within the OSI 
profile, given a logical name known by the application, the Directory Services will provide 
the needed addressing information. However, no specification exists for real time users not 
using OSI as the communication protocol, and since SAFENET allows a non-standard 
approach for the Application, Presentation, and Session layers as well as the Lightweight 
Protocol underneath, a major problem exists here. 

The Lightweight profile’s multicast capability envisioned for SAFENET is limited to 
a single logical LAN segment; this may not be the optimal approach. Naval combat 
platforms in hostile environments should have the ability to broadcast across multiple 
LANs to report tactical and strategic casualties (Engineering, Weapons, etc.) to decision 
makers. The issue of multicast capability to multiple LANs should be reviewed to 
determine its value to decision makers. 

SAFENET addresses the issue of clock granularity, but in terms of clock accuracy, no 
guidance is established for the performance requirements of the individual network clocks 
in a network. Determining the system clock resolution is needed to accurately determine 
the amount of time taken in point to point data transfers. For example, consider a radar 
target that is passed to weapons for engagement. Clock resolution and synchronization is 
what is required in this real time scenario for a successful engagement. Without these two, 
resolution and synchronization, how can a target be engaged, if we do not know whether 


the data is late, therefore useless or an actual prediction. This issue of clock performance, 
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resolution and synchronization is a potential pitfall because the determination of what is 
“sufficient” component quality is left up to the system engineer. 

Security as pertains to the protection of data that is transferred on the network is the 
final area of concern. Although it may not be necessary for all implementations of 
SAFENET to provide security services, security implementations will be necessary in 
some platforms. For example, a platform with an implementation that involves data 
transfers of multiple classification will require a risk analysis to determine which security 
services to provide. Satisfying the security requirements as provided in MIL-HDBK-818- 
1 (still in drafting stage) may prove difficult to implement and yet, still conform to 
SAFENET’s standard. 
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v. TESTING FIBER OPTIC LINKS 


The design points for a communication link are many and require careful 
consideration. The band width-length specified for SAFENET Laser or LED with 
multimode, graded index fiber can support data rates from 10 to several hundred Mbps over 
distances ranging from 10 meters to 200 kilometers. To design a reliable SAFENET 
communications data link, a through survey and analysis of system requirements is 
necessary. 

The maximum tolerable bit error rate for the system must be determined. The bit error 
rate is the probability that an error has been detected in a received bit. The determination 


of the bit error rate is a critical element in the total SAFENET communications system 
performance. The bit error rate for a metallic connection is approximately 10°; whereas, a 


bit error rate of 10° is commonly used for fiber optic data links. The bit error rate is also a 
product of receiver sensitivity. The total allowable power loss for the link is the difference 
in the power provided by the source and the power required by the detector. Additionally, 
some spare power must be present to account for temperature variations, diode aging and 
bend loss on the fiber. The above criteria represent the major points in fiber optic data link 
design. 

In the case of ANSI FDDI, the single most important factor is the bit error probability 


(P.). If the P, is too high, the need for frame retransmission occurs more frequently; if it is 


too small, the system will be prohibitively expensive. The P, for FDDI is 2.5 x 10°! which 


is easily attainable with current optical fiber technology. As long as the signal-to-noise ratio 


is sufficient, the required P, is attainable. Conversely, if the signal-to-noise ratio ts 


insufficient, the P, will tend toward certainty (1). 











A. LOSS BUDGET 


A loss budget analysis is important for ensuring that the SAFENET system will meet 
or exceed performance limits. In conventional radio frequency systems like Ethernet or 
Token Ring, the signal-to-noise ratio must be large enough to support a specified P,. For an 
optical system, the goal is the same, but the calculations are based on losses specific to the 
optical net. The ANSI FDDI standard specifies a P, of less than 2.5 x 10°10 [ANNA88]. 
Robert Kimball provides a detailed explanation of the different losses associated with 
FDDI [KIMB89]. The reason for conducting this analysis is to determine whether or not 
the installation will meet the FDDI requirements and thus be in conformance with 


SAFENET. The general form of the decision statistic is: 


sity x les 


P represents the available power, defined as 11 dB for FDDI. The first term on the right 


hand side of the inequality, Hy. is the sum of the aggregate component losses in the link. 


These losses include propagation losses due to irregularities in the fiber, connector losses, 
splice losses, higher order mode losses (due to refraction inside the fiber), and the Media 
Interface Connector (MIC) ferrule delta. The MIC ferrule delta accounts for the difference 
between the precision test ferrule and a production ferrule [KIMB89]. MIC is the plug and 
receptacle pair that makes the physical connection between the optical fibers and the 
transmitter or receiver. 


The second term on the right hand side, dq? is the dispersion penalty, which accounts 


for dispersion losses in the optical fiber. This is a function of bit rate and of several 
chromatic characteristics of the LEDs used in FDDI. Within the dispersion penaity 
equation, the average segment length component accounts for links that consist of several 


spliced segments. This accounts for the bandwidth concatenation phenomena, which may 
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cause a bandwidth increase in concatenated fibers over what is normally expected in a 
single, unbroken fiber. 


The third term on the right hand side, Hoo is the system margin. It represents a 


catch-all that allows for variations in the cable plant and a factor that compensates for 
timing variations between the light level at the output of the fiber and the light received at 


the lens on the receiver. 


The final term on the right hand side, 2 at is the total variance of the link loss 
T 


distribution and is defined as a function of the variances of the dispersion penalty and the 
loss distribution. 

The final step is to substitute all the intermediate results for the right hand side terms 
back into the original equation to verify that we have not exceeded the loss budget. If the 
right hand side of the equation exceeds 11 dB, one would need to go back to the SAFENET 
installation and figure out where the loss budget can be improved. The area that would 
provide the greatest change with the least effort would be the aggregate component loss 
factor. Two ways to improve this factor would be to shorten the links between transmitter 
and receiver or reduce the number of connectors. Obviously, there will be instances where 
it is impractical to alter this component; consequently, other components on the right hand 


side of the inequality will have to be evaluated. 


B. SYSTEM THROUGHPUT 

Theoretically, networks can approach 100% transmission efficiency, but there are 
certain tade-offs to be addressed. Contention based protocols which approach 100% 
transmission efficiency have excessive wait delays associated with them. Collision free 
protocols such as ANSI FDDI are better suited for approaching the transmission efficiency 


limit. 
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1. Clock Accuracy Verification 
Timing analysis is critical to determining how well the SAFENET system 
performs over the network. Recent studies have shown that bottlenecks (choke points) in 
the protocol stacks and the processors are more detrimental to network speed than the raw 
data transfer rate. In order to determine how well the SAFENET profiles perform, it is 
necessary to time different data transfers and compare them. Determining the system clock 
resolution is needed to accurately determine how long data transfers from one point to 


another take. Inaccurate timins -voulc - -opardize the validity of any data collected. 


2. Timing Test Procedure 

To attain a more meaningful result from data transfer analyses, data transfers 
should be conducted under normal net loading and under no load “ideal” conditions. Test 
sets should consist of two groups of file transfers. The test files should be selected based on 
size. The criteria for size is outlined in the following paragraphs. 

The largest data set must be large enough to exceed the size of the buffers on the 
interface cards. Care must be taken in selecting an appropriate size file and yet minimize 
the effects (by percentage) of overhead. 

The next file has to be smaller than the aforementioned file, but larger than the size 
of an FDDI packet. The space reserved for data is 4478 bytes in an FDDI packet. Once 
more, care must be taken to select an appropriate size file while minimizing the effects (by 
percentage) of overhead. FDDI has no minimum packet size. Percentage of overhead is 
calculated by dividing the number of bytes of overhead by the number of data bytes, then 
multiplying the result by 100. 

Validating operational specifications set forth by manufacturers and SAFENET’s 
standard and testing for proper installation are dominant reasons for collecting system 
measurements. Of particular interest are the fiber attenuation, band width, bit error rate, 
transmitter and receiver coupled power, connector loss, splice loss and the signal-to-noise 


ratio. Some measurements for conformance determination are to be taken before, during 
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and after installation. Fortunately, test equipment in conjunction with the theoretical and 
empirical analyses are available to measure and test each area of concern. The Consultative 
Committee International Telegraph and Telephone (CCITT) has _ produced 
recommendations for test methods to which, it is hoped, most SAFENET component 
manufacturers and test equipment manufacturers will adhere. The testing procedure is, test 
all parts and components before installation, test all parts and components after installation, 
and perform integration tests by testing subsystems and entire systems after installation. 
For complete systems tests, ensure data test sets emulate valid data; this will ensure that the 


results obtained are meaningful. 
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VI. TESTING SAFENET’S IMPLEMENTATION PROFILES 


A. TEST METHOD 

In this section, the test procedure is described; the following description is actually a 
refinement of the method described in [MILL90]. From the SAFENET standard, Finite 
State Machine Diagrams of the protocols contained within the SAFENET profiles were 
created. From these diagrams, predicate-action tables for systems of communicating 
machines were created for the OSI and Light Weight implementations. The test procedure’s 
initial input is a protocol specified as a system of communicating machines and the output 
is a complete test sequence and an Input/Output diagram. In order to proceed from the 
specification of a protocol machine or profile implementation to a test sequence, 
identification of the shared and local variables is necessary. The shared and local variables 
present a way for the tester to provide input to and observe output from the machine during 
testing. The test of each edge, transition, is treated as a separate, individual test, and may 
modify some or all of the.shared and local variables. 

The format of each single edge, transition sequence is 

Sy ipsg,..-ip/0,02,..-0m SE 

where Sy; is the state of the machine at the start of the test, i,,i7,...i, are the values of 

the input variables before the test, 01,09,...0,, are the values of the output variables after the 


test, and Sx is the state of the machine at the end of the test. The input and output variables 


are determined before testing begins and are taken from the shared and local variables of 
the machine or profile. The procedure consists of preliminary steps, the test sequence 


generating procedure, and refining steps. 
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1. Preliminary Steps 

1. From the machine specification finite state diagram, mark each transition 
whose name appears on more than one transition or edge. Each such instance for a given 
name is given a separate distinguishing label. 

2. From the predicate-action table note the number of distinct conditions or 
clauses in each enabling predicate. Mark each clause. 

3. For each shared variable x, determine if x is an input variable, output variab’ 

or both an input and output variable. For each x which is both input and output, split x into 


two variables, x; and Xo for testing purposes. 


4. For each local variable 1, determine if | is used as an interface to the higher 
layer user of this profile or protocol. If such is the case, mark | as input, output or both. Each 
such local variable is an input variable if it appears in an enabling predicate and a output 
variable if it appears in an action on the left side of an assignment arrow. If 1 is both input 
and output, it is split into variables |; and Ig for testing purposes. 

Step 1 is to ensure that each instance of each transition is tested. A protocol 
specification may have the same transition name on more than one arc; this step provides a 
degree of certainty that every arc is tested. Step 2 ensures that each clause is tested 
individually, if possible. An enabling predicate may consist of several clauses, any one of 
which may be true, allowing the transition to execute. In steps 3 and 4, the shared and local 
variables are identified. Shared variables provide the means of communication between the 
machine and other protocol entities within a profile. Local variables allow communication 
with the user of the protocol or profile. In essence, these variables are the means the test 
designer has of giving inputs to the machine and observing its actions. 

In some system of communicating machine specifications, additional variables are 
defined that are used internally by the protocol or profile machine and are not visible to the 


user (upper layer(s) of the protocol) or the tester. Typically, such variables are counters or 
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array indices. These variables should not appear in the test sequence as they are not under 


the direct control or observation of the tester. 


2. Test Sequence Generating Procedure ; 


1. S,€ initial_state 


2. Let t = (p,a) be an untested transition from an arbitrary state. What this 
notation means is that the current transition being tested , t, has the predicate, p, as input 
and the action,a, as output. 

(a) Determine the values of the input variables which make exactly one of the 
untested values of p true. Check to see if these values allow any other transition from this 
state to be executed. If so, set additional input variables to values that ensure that only the 
transition being tested is enabled. Fill in the necessary input variables, and mark the others 
DC for “don’t care.” 

(b) Determine and mark the expected values for the output variables. In addition 
record the expected values assumed by the local variables. 

(c) Determine the expected next state and set Sx to it. 

(d) Determine if Sz is transient; if it is not, label it as a “stop state” and proceed 
to step 3. Within the confines of the test procedure, a state is transient if one or more of its 
enabling predicates is true upon reaching the state. This means that the machine can 
proceed to another state without having to wait for further input from the tester. 


(e) Attempt to make Sg into a stop state by setting DC values such that when 
state Sp is reached, none of its enabling predicates are true. If successful, proceed to step 3. 
(f) Sg is a transient state. If more than one transition leaving Sg is enabled, 


arbitrarily select one and set the input not yet specified, such that only one transition leaving 


Sx is enabled. Set t = (p,a) to this transition. 


3. Output this test Sy ij, i7,...ip/01,02,...0, Sg as the next test in the sequence. 





4, Mark the clause just tested. If all clauses in transition t are now tested, mark 
t as tested. If all transitions are now marked as tested, exit to “refining steps.” Otherwise, 
proceed to step 5. 

5. Set S; to Sg. If S; is a stop state, proceed to step 2,; otherwise, proceed to 
step 2(b). 

Step 2(a) attempts to test each clause separately. For well designed protocols this is 
generally true. It is vital in that the tester knows which transition was enabled, and as a 
result, caused the transition to occur. In the event that it is not possible to individually test 
each clause, the test designer must set the input variables such that the clauses are tested as 
meticulously as possible. It is quite possible that such clauses may be tested in conjunction 
with one another. However, if a clause cannot be tested individually, the question of clause 
necessity to the specification arises. 

Steps 2(d), 2(e) and 2(f) are concerned with transient states. If execution of a state 
immediately enables another transition, it may prove difficult or even impossible for the 
tester to verify that the values contained in the output variables are as expected. For such a 
circumstance, the transient state and possible multiple enabling transitions that can not be 
controlled with these test methods, could indicate the need to modify the specification for 
better testability. 

Step 5 initializes the start state of the next test in the sequence to the ending state of 
the current test. The advantage here is that the ordering of the tests follow the order of their 
occurrence in the actual profile implementation. In order to exercise all parts of a protocol 
or profile implementation,some transitions may have to be executed more than once. In 
such a circumstance, judgement by the test designer may be needed. This is not necessarily 
a cause for concern; in the normal operation of a profile or protocol machine, certain 
transitions may be executed more than others. Consequently, during testing the same trend 


will likely be true. 








3. Refining Steps 

1. Construct the Input/Output state diagram from the test sequence. In this step, 
the stop state information is also used, assuming that there is at least one stop state. 

2. For each state, determine a shortest Unique Input/Output (UIO) sequence (if 
one exists). Append the UIO sequence for Sx to the end of the test sequence. If no UIO 
sequence for the current Sp exists, continue testing transactions (extending the sequence) 
until an Sg with a UIO is visited. 

3. Check for converging transactions which are difficult to test and may require 
special handling. These transactions are marked as potential problems. 

In step 1, the Input/Output diagram is constructed from the test sequence and is a tool 
to help the test designer ensure completeness. This diagram is constructed directly from the 
test sequence with the knowledge of “stop states.”’ The diagram’s initial state will be initial 
state S;; additional states are added for each stop state is encountered. The arcs are directed, 
and labeled with the with the values of the input and output variables. 

The I/O diagram generated from the test sequence can be viewed as an incomplete 
finite state machine specification. However, there is a relationship to the specification 
machine, because there is a tour through the specified transactions. It is not identical to the 
specification; there are states which are transitory in the specification and does not appear 
in the IO diagram. 

The purpose of the final UIO sequence in step 2 serves to verify that the last state 
which was reached in the test sequence is indeed the current state of the protocol or profile 
machine. Because the details of the machine’s implementation are assumed to be “hidden” 
from the tester, the existence of at least state with a UIO sequence is necessary. Without the 
UIO sequence, there is no way of knowing if the last transition tested, left the machine in 
the expected state. 


In actuality, the converging transitions, identified in step 3, are distinct transactions, 


with identical labels, which originate from different states but terminate at the same state. 





The existence of converging conditions can not be eliminated always and, therefore, 
complicates the role of the test designer and makes error detection difficult. These 
circumstances may naturally occur in the specification of a protocol, but should be marked 


for special observation. 


B. APPLICATION OF TEST METHOD 

In this section the test generating procedure is illustrated using derived specifications 
for two of the SAFENET standard profiles: OSI profile and Lightweight profile. The 
profiles are first specified as a system of communicating machines and then the procedure 


is given. 


1. OSI Profile Specification 

The specification of the OSI profile consists of the predicate-action table (Table 
1), the specification for each protocol within the profile, given in Figure 8, and the inter- 
process shared variable MEDIUM, shown in Figure 9. The single intra-process shared 
variable Transfer is used to model the network node’s internal bus, which is shared by the 
protocols within a node or station. An internal transmission is modeled by a write into this 
shared variable. The first field “Transfer.T” takes the value T or F, which is used to indicate 
whether the frame represents a time synchronization frame or a data frame. The second 
field, DA for Destination Address, contains the address of the protocol machine to which 
the message is transmitted. The next field, SA for Source Address contains the originator’s 
address. Fields four through eleven contain the values T or F and are used to control the 
intra-process routing; based on the values contained in these variables, the frame’s 
Destination Address is determined. Finally, the data field contains the data block itself. The 
single shared variable MEDIUM is used to model the bus, which is shared by each machine 
or network node. A transmission onto the bus is modeled by a write into this shared 
variable.The first field “MEDIUM.T” takes the value T or F, which is used to indicate 


whether the frame represents a time synchronization frame or a data frame. The second 
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field, DA for Destination Address, contains the address of the network station to which the 


message is transmitted. The next field, SA for Source Address contains the originator’s 
address; finally, the data field contains the data block itself. 

The OSI profile is defined by a finite state machine, a set of local variables and a 
predicate-action table. The initial state of each profile machine is state 0, and the shared 
variables MEDIUM and Transfer are initially set to contain the respective address of one 
of the stations or protocol machines in the DA field. 

The local variables inbuf, outbuf, etc. are used for storing data blocks to be 
transmitted to or received from other protocols. Outbuf is an array, and can store a 
potentially large number of data blocks. 

The initial state of each profile machine is state 0 and all local variables are 
initially set to empty. The inter-process shared variable MEDIUM initially contains the 
address of one station in its DA field. Therefore, the initial system state tuple is (0,...,0) and 
the first transition taken by a station holding the token will be xmit_time, or xmit_msg. 

Each profile machine has 18 states. In the initial state, 0, the station is quiescent, 
merely waiting for an incoming message, a transmit message signal, or a transmit time 
synchronization signal. If a frame appears. in the variable MEDIUM with the network 
node’s own address, the transition to state 1 is taken. When taking the xmit_time transition, 
in State 2, the station transmits the data blocks that it has via Transfer, moving to state 3. In 
state 3, the station transmits the data blocks it has, moving to state 6. As specified by the 
SAFENET standard, synchronization frames are sent via the ISO CLNP Protocol 
[HDBK92] page. 37. In state 6, the data blocks are formed into datagrams and transmitted, 
moving to state 17. In state 17, the station transmits any data blocks it has moving to state 
18. In state 18, the station transmits until its token holding time expires or all of its 
messages are sent; the station then returns to state 0. When taking the 
xmit_clear_logical_msg transition, in state 8, the station transmits the blocks that it has, 
moving to either state 9, state 10 or state 11. If in state 9, the station transmits the data 


blocks it has moving to state 14. If in state 10, the station transmits the data blocks it has 
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moving to state 14. If in state 11, the station transmits the data blocks it has moving to state 
12. From state 12, the station transmits the data blocks it has moving to state 13. If in state 
13, the station transmits the data blocks it has moving to state 14. If in state 14, the station 
transmits the data blocks it has moving to state 15. From state 15, the station moves to 

‘ station 16 after transmitting its data blocks. When in state 16, the station transmits the data 
blocks it has moving to states 4, 5, or 6; this transition is based on the message size and its 
destination address’ location. If in state 4, the station transmits the data blocks it has 
moving to state 17; from states 5, or 6, the station transmits its data blocks, moving to state 
17. In state 17, the station transmits any data blocks it has moving to state 18. In state 18, 
the station transmits until its token holding time expires or all it messages are sent; the 
station then returns to state 0. 

The receiving profile station, like all other stations not in possession of the token, 
will be in state 0. The message will appear in MEDIUM, with the receiving station's 
address in the DA field. The receive transition to state 1 will be taken. In state | the data 
block is copied and the MEDIUM is cleared by the ready transition. By clearing the 
MEDIUM, the receiving station enables the sending station to return to its initial state (0) 
or its sending state (18). . 

For this simplified high-level specification, the channels inter-process and intra- 
process are assu) 1ed to be error free. This means that the clearing of the medium by the 
receiver can be taken as an acknowledgment by the sender. Hence, there is no requirement 
for timers, time-outs or error checking on the channel. Although some of the finer details 


of the OSI profile are omitted, this specification contains the main idea of the OSI profile, 


and provides sufficient detail for the generation of a test sequence. 
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Figure 8 OSI Profile Specification 
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Each machine within the OSI profile in Figure 8 performs the following: 


« StateQ In the initial state, the machine is quiescent, merely waiting to process a request 
or transmission. 

- State 1 In the receive state, the machine copies an incoming message from the bus and 
acknowledges receipt of the message by clearing the bus. 

«State 2 The SAFENET Time Service protocol provides for the distribution of time 
information and the synchronization of distributed clocks within a system. 

«State 3. In addition to Lightweight and Xpress Transfer Protocol support, the OSI 
Connectionless transport protocol directly supports STS’s protocol data unit 
transfer. It provides the user with the ability to transmit a single unit of data, 
datagram, without the requirement of a connection being established. 

*State4 The ISO End System-to-Intermediate System routing exchange protocol passes 
address information among all stations that are on the same LAN segment or 
through intermediate stations. The ES/IS protocol provides stations with the 
ability to associate a data link layer address with a given network layer address. 

¢State5 The ISO Intermediate System-to-Intermediate System intra-domain routing 
protocol provides SAFENET networks with dynamic determination of routes 
used to pass data between intermediate systems. 

*State6 The ISO Connectionless Network protocol provides services for network routing 
and for the segmentation and reassembly of transport layer messages that are 

' too large for the underlying communications service. Additionally, the ISO 
CLNP has multicast data transfer capability, but limits the scope of transfers to 
users on a single LAN segment. 

«State 7 The Private Communications protocol provides a means for secure 
communications between network stations. 

+ State 8 The Directory Services provides a mapping from “user friendly” names 
(application entity titles) to presentation service access point addresses 
required in communication instances. 

«State 9 The File Transfer, Access, and Management protocol provides services for 
transferring information in the form of files among application processes and 
file stores. 

« State 10 The Association Control Service Element protocol provides services for the 
establishment and termination of application layer associations and a standard 
service for application layer protocols to communicate common parameters. 

«State 11 The System Management Application Service Element protocols specifies the 
management functions which are supported in a system node, and defines the 
semantics and abstract syntaxes of information transferred. It uses CMISE for 
communication. 

* State 12 The Common Management Information Service Element protocol provides a 
common message framework for management procedures supplying both data- 
manipulation and notification/operation-oriented services. 

« State 13 The Remote Operations Service Element protocol is used in support of CMISE, 
and provides a simple, uniform service for remotely invoking operations and 
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then receiving correlated replies to those operations. 

«State 14 The ISO Presentation protocol is concerned with the syntax of data the data 
exchanged between application entities and resolves differences in format and 
data representation. The presentation layer defines the syntax used between 
application entities and provides for the selection and subsequent modification 
of the representation to be used. 

- State 15 The ISO Session protocol provides the mechanism for controlling the dialogue 
between applications. At a minimum, it provides a means for two application 
processes to establish and use a connection. 

+ State 16 The ISO Connection-Oriented Transport protocol provides for the 
establishment, maintenance, and termination of a logical connection between 
transport users. It allows connection-related features such as flow control, error 
control, and sequenced delivery. 

+ State 17 The Logical Link Control protocol provides three services: Unacknowledged 
connectionless service which supports point-to-point, multipoint and broadcast 
in a datagram style of service, Connection-oriented services which provides 
flow control, sequencing, and error recovery, Acknowledged connectionless 
service which provides for acknowledgment of individual frames and supports 
point-to-point transfers. 

- State 18 The FDDI Token LAN protocol provides the ability to get data on and off the 
physical medium in a controlled manner. 
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Table 1: OSI PREDICATE-ACTIONS 


LAI LR pieeemaermmny v-'-~ penaaiamaciaane 
receive inbuf ~ MEDIUM 

ready [me SSS*dYCMEDIUM 

xmit_time Transfer <— outbuf (n) a outbuf(n) —@ 
sts_msg Transfer < sts_msg A sts_msg <— @ 
pnivate_msg (p_msg) Transfer <— p_msg A p_msg < @ 
xmit_clear_logical_msg Transfer — xclma xclm¢e- @ 
Xmit_private_logical_msg}xplm (p, m, data) = (true, true, msg) Transfer — xplma xplme SD 


xmit_clear_msg (xcm) |xcm(p,m,smase) = (false, false, true Transfer — xcma xcme @ 
xmit_clear_msg (xcm) |xcm(p,m, acse) = (false, false, true) Transfer — xcma xcm¢ © 


xmit_clear_msg (xcm) |xcm(p,m,ftam) = (false, false, true) Transfer — xcmaxcme @ 


xmit_clear_map_msg m, ftam) = (false, true, true) Transfer <— xcmm a xcmm <- © 


7) 
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3 
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ss) 


xmit_clear_map_msg Kcmm(p,m,smase) = (false, 5 Transfer — xcmm a xcmm + © 


xmit_clear_map_msg xcmm(p, m, acse) = (false, true, true) Transfer — xcmm a xemm + © 
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xmit_private_map_msg m, smase) = (true,true,true} Transfer — xpmma xpmm¢— @ 


xmit_private_map_msg 


ted 
ao] 
3 
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m, ftam) = (true, true, true) Transfer — xpmm a xpmm ¢ © 
xmit_private_map_msg {xpmm (p,m, acse) = (true, true, true) Transfer <— xpmma xpmm ¢ © 
xmit_private_msg (xpm)|xpm (p,m, ftam) = (true, false, true) Transfer <— xpm a xpm e © 
xmit_private_msg (xpm)]|xpm (p, m, acse) = (true, false, true) Transfer — xpm a xpm< © 
Xmit_private_msg (xpm) |xpm (p,m, smase) = (true, false, true) Transfer <— xpm a xpm <- @ 
ftam_msg ftam_msg # D ransfer <— ftam_msg a ftam_msg <— @ 
acse_msg acse_msg # D transfer <— acse_msg a acse_msg <- © 
smase_msg smase_msg # ransfer < smase_msg A smase_msg <— 
cmise_msg cmise_msg # © ransfer <— cmise_msg A cmise_msg <— © 
rose_msg rose_msg # © Transfer <— rose_msg A rose_msg «— © 
presentation_msg (pm) Transfer — pm a pm¢e- OD 
session_msg (sm) Transfer — smasme@D 
co_trans_msg (cotm) cotm #@acotmes = true Transfer — cotm a cotm €— D 
co_trans_msg (cotm) cotm #@ a cotm.is = true Transfer <— cotm a cotm€ @ 
co_trans_msg (cotm) cotn #@ acotm.cl = true Transfer <— cotm A cotm < @ 
cl_trans_msg (cltm) Transfer —cltm a citm -— @ 
es/is_msg es/is_msg #O Transfer <— es/is_msg A es/is_msg < OD 
is/is_msg is/is_msg # OD Transfer <— is/is_msg a is/is_msg «- © 
clnp_msg clnap_msg # © Transfer < clnp_msg a clnp_msg «- @ 
llc_msg lic_msg #3 Transfer <— llc_msg a lic_msg <— @ 
MEDIUMe @ 


msg_sent 


> 
nN 


1. OSI Test Sequence Generation 
First the preliminary steps are carried out; these steps determine the exact format 
of the tests. The measures employed are primarily concerned with input and output 
variables. After the preliminary steps, the tests are generated. For ease of reference the 


numbering below corresponds to the steps in the test procedure. 


a. Preliminary Steps 

(1) From Figure 8’s Lightweight profiie specification finite state diagram, we 
see that all transition labels are unique; therefore, no action is required. 

(2) All transitions have single clause enabling predicates; therefore, no action 
is required. 

(3) The shared variable MEDIUM is both an input and an output variable; 
therefore it is split into two variables MEDIUM, and MEDIUMo for testing purposes. The 
intra-process shared variable Transfer is both an input and an output variable; therefore it 
is split into two variables Transfer; and Transferg for testing purposes 

(4) The local variables outbuf, sts_msg, private_msg, 
xmit_private_logical_msg, xmit_clear_logical_msg, xmit_clear_msg, 
xmit_clear_map_msg, xmit_private_map_msg, xmit_private_msg, ftam_msg, acse_msg, 
smase_msg, cmise_msg, rose_msg, presentation_msg, session_msg, co_trans_msg, 
cl_trans_msg, lic_msg, clnp_msg, es/is_msg and is/is_msg are both input and output 
variables; therefore they are split into two respective variables, for example private_msg, 
and private_msgo, for testing purposes. 

Note that in step 2, the co_trans_msg and xmit_time are not separated into 
twodifferentclauses because both conditions must be true for the transition to be enabled. 

From these preliminary steps, we can see that the test will adhere to the 
following form: 


S; MEDIUM, Transfer, outbuf}... Iic_msg; / MEDIUMg Transfer outbufo... 


lic_msgo inbuf Sg 


43 


Now we are ready to begin generating the test sequence. 


b. Test Sequence Generation 

(1) We begin in the initial state, 0. In step 2 we may choose any untested 
transition emanating from state 0; we select the xmit_clear_msg transition.(step 9). 

2(a) According to the predicate-action table, to enable this transition the local 
variable xmit_clear_msg must contain data for processing and the DA field of xmit_msg is 
assumed to be state 9’s address. The remaining fields may have any values, and are 
indicated by an “x” in Table 2. The other input variables are set to DC for “don’t care.” 

2(b) When the transition occurs, Transfer copies the data from 
xmit_clear_msg, and xmit_clear_msg is set to empty. 

2(c) Sg is set to the expected end state for this test, which is state 9. 

(3) Noting that the next state is a stop state, this completes the first test in the 
sequence, and the appropriate values are shown in Table 2. 

(4) This clause and transition are now marked “tested.” 

(5) The value of S; is now set to 9 and another iteration starting at step10 is 
called for. 

The next iteration of the procedure selects the ftam_msg transition, and the values 
selected are shown as the tenth test entered in Table 2. The expected ending state for this 
tenth test is 14. The next iteration of the procedure selects the presentation_msg transition, 
and the values selected are shown as the eleventh test entered in Table 2. The expected 
ending state for this tenth test is 15. From state 15 in test step 12, we take the session_msg 
transition. The expected ending state resulting from this transition is 16. 

At the next iteration, the co_trans_msg transition is taken; the expected ending state 
for this thirteenth test is 4. From state 4, we take the es/is_msg transition. In test step 
fourteen, the expected ending state resulting from this transition is 17. From state 17, we 


take the llc_msg transition; the expected ending state for this fifteenth test is 18. From state 





18, we exercise the msg_sent transition using the “true” predicate, which leads back to the 
initial state. 
The remaining untested transitions are executed in a similar manner resulting in a final 


test sequence of 356 steps. The values of the input and output variables for all of these tests 


are shown in the appendix. 
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2. Lightweight Profile Specification 

The specification of the Lightweight profile consists of the predicate-action table 
(Table 2), the specification for each protocol within the profile, given in Figure 10, and the 
inter-process shared variable MEDIUM, shown in Figure 11. The single intra-process 
shared variable Transfer is used to model the network node’s internal bus, which is shared 
by the protocols within a node or station. An internal transmission is modeled by a write 
into this shared variable. The first field Transfer.T takes the value T or F, which is used to 
indicate whether the frame represents a time synchronization frame or a data frame. The 
second field, DA for Destination Address, contains the address of the protocol machine to 
which the message is transmitted. The next field, SA for Source Address contains the 
originator’s address. Fields four through eleven contain the values T or F and are used to 
control the intra-process routing; based on the values contained in these variables, the 
frame’s Destination Address is determined. Finally, the data field contains the data block 
itself. The single shared variable MEDIUM is used to model the bus, which is shared by 
each machine or network node. A transmission onto the bus is modeled by a write into this 
shared variable. The first field MEDIUM.T takes the value T or F, which is used to indicate 
whether the frame represents a time synchronization frame or a data frame. The second 
field, DA for Destination Address, contains the address of the network station to which the 
message is transmitted. The next field, SA for Source Address contains the originator’s 
address; finally, the data field contains the data block itself. 

The Lightweight profile is defined by a finite state machine, a set of local variables 
and a predicate-action table. The initial state of each profile machine is state 0, and the 
shared variables MEDIUM and Transfer are initially set to contain the respective address 
of one of the stations or protocol machines in the DA field. 

The local variables inbuf, outbuf, etc. are used for storing data blocks to be 


transmitted to or received from other protocols. Outbuf is an array, and can store a 


potentially large number of data blocks. 











The initial state of each profile machine is state 0 and all local variables are 


initially set to empty. The inter-process shared variable MEDIUM initially contains the 
address of one station in its DA field. Therefore, the initial system state tuple is (0,...,0) and 
the first transition taken by a station holding the token will be xmit_time, or xmit_msg. 

Each profile machine has 10 states. In the initial state, 0, the station is quiescent, 
merely waiting for an incoming message, a transmit message signal, or a transmit time 
synchronization signal. If a frame appears in the variable MEDIUM with the network 
node’s own address, the transition to state 1 is taken. When taking the xmit_time transition, 
in state 2, the station transmits the data blocks that it has via Transfer, moving to state 3. In 
state 3, the station transmits the dita blocks it has, moving to state 8. As specified by the 
SAFENET standard synchronization frames are sent via the [SQ CLNP Protocol 
{HDBK92] page. 37. In state &, the data blocks are formed into datagrams and transmitted, 
moving to state 9. In state 9, the station transmits any data blocks it has moving to state 10. 
In state 10, the station transmits until its token holding time expires or all it messages are 
sent; the station then returns to state 0). When taking the xmit_msg transition, in state 4, the 
station transmits the blocks that it has, moving to either state 3 or state 5. If in state 3, the 
station transmits the data blocks it has moving to states 6, 7, or 8: this transition is based on 
the message size ind its destination address” location. If in state 5, the station transmits the 
data blocks it has moving to states 6, 7, 8, or 9: From states 5, 6, 7, or 8, the station transmits 
its data blocks, moving to state 9. In state 9, the station transmits any data blocks it has 
moving to state 10. In state 10, the station transmits until its token holding time expires or 
all of its messages are sent: the stauion then returns to state 0. 

The receiving protile station, like all other stations not in possession of the token, 
will be in state 0. The message will appear in MEDIUM, with the receiving station’s 
address in the DA field. The receive transition to state | will be taken. In state | the data 
block is copied and the MEDIUM is cleared by the ready transition. By clearing the 
MEDIUM, the receiving station enables the sending station to return to its initial state (0) 


or its sending state (10) 


For this simplified high-level specification, the channels inter-process and intra- 
process are assumed to be error free. This means that the clearing of the medium by the 
receiver can be taken as an acknowledgment by the sender. Hence, there is no requirernent 
for timers, time-outs or error checking on the channel. Although some of the finer details 
of the Lightweight profile are omitted, this specification contains the main idea of the 


Lightweight profile, and provides sufficient detail for the generation of a test sequence. 


Table 3: LIGHTWEIGHT PREDICATE-ACTIONS 


CCAAETRUEATUEAEERTREERRERAE ETAT RARER TREATED EA HELO OOOODONSOROODSEOSOSDOOONOONOSOUDNSOOSDOEONSSODSUNDSRONSSONSONQUONSADDINNIND 


Transition Predicate Action 
Teceive inbuf — MEDIUM 
ready true MEDIUMe @ 
xmit_time outbuf(n) +O Aaoutbuf (a) t =true{ Transfer — outbuf(n) a outbuf(n) —@ 
sts_msg sts_msg (t, data) = (true, msg) Transfer < sts_msg 


xmit_msg xmit_msg # D Transfer <— xmit_msg A xmit_msg <- @ 
lightwt_cl_msg (Iwem) Transfer <— lwem a lwcm <— @ 


xfer_xtp_msg (xxm) Transfer <~ xxm A xxm <— @ 


cl_msg (xpm) xpm(t,cl) = (true, true) Transfer ~ xpm A xpm< @ 
xtp_rte_msg (xrm) wm (t,es) = (true, true) Transfer <— xrm a xrm + © 
xtp_rte_msg (xrm) xrm (t,is) = (true, true) Transfer — xrm a xrm — @ 
xtp_tte_msg (xrm) xm (t,cl) = (true, true) Transfer’ <— xrm a xm <— @ 
es/is_msg es/is_msg # D Transfer <~ es/is_msg A es/is_msg <— © 
is/is_msg is/fis_msg # @ Transfer < is/is_msg A is/is_msg <— © 


clnp_msg clnp_msg + © Transfer <~ clnp_msg A clnp_msg <- 
xtp_msg xtp_msg #@ Transfer <- xtp_msg A xtp_msg < © 
llc_msg lc_msg # O Transfer < Ilc_msg a Ilc_msg < © 


MEDIUM<e- @ 


msg_sent 








msg_sent 









1 
Receive 
State 





xmit_time 


lightwt_cl_msg 


assur dix 


Figure 10 Lightweight Profile Specification 
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Each machine within the Lightweight profile in Figure 10 performs the following: 


+ State O In the initial state, the machine is quiescent, merely waiting to process a request 
or transmission. 

» State 1 In the receive state, the machine copies an incoming message from the bus and 
acknowledges receipt of the message by clearing the bus. 

«State 2 The SAFENET Time Service protocol provides for the distribution of time 
information and the synchronization of distributed clocks within a system. 

+ State 3. In addition to Lightweight and Xpress Transfer Protocol support, the OSI 
Connectionless transport protocol directly supports STS’s protocol data unit 
transfer. It provides the user with the ability to transmit a single unit of data, 
datagram, without the requirement of a connection being established. 

-State4 The Lightweight application services consist of a set of communication service 
primitives which can be implemented to provide a user with direct, efficient 
data transfer capabilities. 

«State 5 The Xpress Transfer protocol provides services which achieve increased 
efficiency and performance by combining the connection process with the data 
transfer process. 

+State6 The ISO End System-to-Intermediate System routing exchange protocol passes 
address information among all stations that are on the same LAN segment or 
through intermediate siations, The ES/IS protocol provides stations with the 
ability to associate a data link layer address with a given network layer address. 

«State7 The ISO Intermediate System-to-Intermediate System intra-domain routing 
protocol provides SAFENET networks with dynamic determination of routes 
used to pass data between intermediate systems. 

«State 8 The ISO Connectionless Network protocol provides services for network routing 
and for the segmentation and reassembly of transport layer messages that are 
too large for the underlying communications service. Additionally, the [SO 
CLNP has multicast data transfer capability, but limits the scope of transfers to 
users on a single LAN segment. 

-State9 The Logical Link Control protocol provides three services: Unacknowledged 
connectionless service which supports point-to-point, multipoint and broadcast 
in a datagram style of service, Connection-oriented services which provides 
flow control, sequencing, and error recovery, Acknowledged connectionless 
service which provides for acknowledgment of individual frames and supports 
point-to-point transfers. 

+ State 10 The FDDI Token LAN protocol provides the ability to get data on and off the 
physical medium in a controlled manner. 
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Figure 11 Lightweight Network Nodes Data Structure 
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3. Lightweight Test Sequence Generation 
First the preliminary steps are carried out; these steps determine the exact format 
of the tests. The measures employed are primarily concerned with input and output 
variables. After the preliminary steps, the tests are generated. For ease of reference the 


numbering below corresponds to the steps in the test procedure. : 


a. Preliminary Steps 

(1) From Figure 10’s Lightweight profile specification finite state diagram, 
we see that all transition labels are unique; therefore, no action is required. 

(2) All transitions have single clause enabling predicates; therefore, no action 
is required. 

(3) The shared variable MEDIUM is both an input and an output variable; 
therefore it is split into two variables MEDIUM] and MEDIUM for testing purposes. The 
intra-process shared variable Transfer is both an input and an output variable; therefore it 
is split into two variables Transfer; and Transferg for testing purposes 

(4) The focal variables outbuf, sts_msg, lightwt_cl_msg, cl_msg, 
xtp_rte_msg, xtp_msg, Ilc_msg, xmit_msg, xfer_xtp_msg, clnp_msg, es/is_msg and is/ 
is_msg are both input and output variables; therefore they are split into two respective 
variables, for example xmit_msg,; and xmit_msgo, for testing purposes. 

Note that in step 2, the xtp_rte_msg and xmit_time are not separated into two 
different clauses because both conditions must be true for the transition to be enabled. 

From these preliminary steps, we can see that the test will adhere to the 
following form: 


S; MEDIUM, Transfer, outbuf,... llc_msg; / MEDIUM Transferg outbufy... 


llc_msgo inbuf Sg 


Now we are ready to begin generating the test sequence. 





b. Test Sequence Generation 

(1) We begin in the initial state, 0. In step 2 we may choose any untested 
transition emanating from state 0; we select the xmit_msg transition. 

2(a) According to the predicate-action table, to enable this transition the local 
variable xmit_msg must contain data for processing and the DA field of xmit_msg is 
assumed to be state 4’s address. The remaining fields may have any values, and are 
indicated by an “x” in Table 4. The other input variables are set to DC for “don’t care.” 

2(b) When the transition occurs, Transfer copies the data from xmit_msg, and 
Xmit_msg is set to empty. 

2(c) Sx is set to the expected end state for this test, which is state 4. 

(3) Noting that the next state is a stop state, this completes the first test in the 
sequence, and the appropriate values are shown in Table 4. 

(4) This clause and transition are now marked “tested.” 


(5) The value of S; is now set to 4 and another iteration starting at step 4 is 


called for. 

The next iteration of the procedure arbitrarily selects the lightwt_cl_msg transition, 
and the values selected are shown as the fourth test entered in Table 4. The expected ending 
state for this fourth test is 3. 

At the next iteration, the cl_msg transition is taken; the expected ending state for this 
fifth test is 8. From state 8, we take the clnp_msg transition. The expected ending state 
resulting from this transition is 9. From state 9, we take the Ilc_msg transition; the expected 
ending state for this seventh test is 10. From state 10, we exercise the msg_sent transition 
using the “true” predicate, which leads back to the initial state. 

The remaining untested transitions are executed in a similar manner resulting in a final 


test sequence of 32 steps. The values of the input and output variables for all of these tests 


are shown in Table 4. 
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vi. CONCLUSIONS AND RECOMMENDATIONS 


A. CONTRIBUTIONS OF THIS RESEARCH 


The goal of this thesis was to present a series of test sequences for the SAFENET 
communication protocol. The procedure takes as input high level SAFENET profiles that 
are specified as a system of communicating machines, and gives as output, complete test 
sequences for SAFENET’s OSI and Lightweight profiles. A brief specification of 
SAFENET’s OSI and Lightweight profiles was given using the system of communicating 
machines model, and test sequences were generated. 

The test method described and employed here further demonstrates the flexibility of 
the system of communicating machines model. A protocol can be specified, verified, and 
tested using techniques based on this model. The concept was expanded and applied to a 
high level profile which encompassed several protocols. In the test procedure, all transition 
instances in the finite state machine specification is tested in conjunction with each enabling 
predicate clause. The preliminary steps were employed to determine the input and output 
variables; the sequence generating procedure was employed to assist in fault coverage. The 
example test sequences for the OSI and Lightweight profiles were used to demonstrate the 
application of the specification and testing methods associated with the system of 
communicating machines model. Since these profiles have the potential for wide spread use 
in present and future naval combatants, their existence as system of communicating 
machines model further illustrate the applicability and usefulness of this method. Utilizing 
a protocol specification method which places emphasis on testing yields better results than 
using a specification method that was not designed with conformance testing in mind. 

Some of the current literature discusses the correctness of a test sequence; their 
apparent emphasis is on shortening the sequence length. However, the system of 
communicating machine test procedure emphasizes the ability of the sequence to detect 


errors rather than the achievement of an optimal test sequence length. This test method can 
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a 


only test for the presence of desirable behavior in a protocol or profile machine. Given the 
current level of technology, it is not practical to exhaustively test for the presence of 
undesirable behavior since all possible errors that could occur in an implementation can not 


be foreseen. 


B. AREAS FOR FURTHER RESEARCH 

The issue of security services for data on platforms with a SAFENET implementation 
exercising data transfers of multiple classifications will have to be addressed. Commercial 
LANs have encountered and solved this problem with respect to sharing a LAN with a 
competitor, but with the performance constraints placed upon SAFENET, the completed 
risk ~nalysis should provide some definitive system configuration with respect to security 
services. Consequently, research effort must be expended to directly address this issue. 

With this test method being as straight forward and easy to apply as it is, it should lend 
itself very well to automation; research iiito to the feasibility of this could possibly prove 
very valuable in the wide spread acceptance of this test method. Further research could 
concentrate on decomposing the protocols within a SAFENET profile and applying the test 
method. In addition, future research could concentrate on extending the error detection 


capabilities to detect multiple errors or to detect them in the presence of converging 


transitions. 
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